10장. 다시 처음으로 — 트레이드오프로 본 스트리밍
10.1 우리가 따라온 질문
이 책의 도입부에서 다음 질문들로 시작했다.
- 왜 HLS는 라이브에서 늦을까
- m3u8 안의 각 태그는 무엇을 의미하는가
- TS 패킷과 fMP4 box는 실제로 어떻게 생겼는가
- 왜 LL-HLS는 데이터 포맷까지 바꿔야 했을까
- Safari와 Chrome은 왜 다르게 동작할까
- MSE 코드는 어떤 모습인가
- Low Latency는 결국 무엇을 바꾸는 일인가
이제 답을 정리할 수 있다.
정리
| 질문 | 답 |
|---|---|
| 왜 HLS는 늦은가 | 안정성을 위해 의도적으로 기다리도록 설계됨 |
| m3u8 태그 | 3장, 6장에서 다룸 |
| TS / fMP4 내부 | 4장에서 다룸 |
| 왜 LL-HLS는 fMP4인가 | 독립 디코딩 가능한 조각이 필요했기 때문 |
| Safari가 다른 이유 | 시스템이 재생 제어권을 가지고 있음 |
| MSE 코드 | 데이터를 직접 buffer에 넣는 구조 |
| Low Latency | 데이터 구조 + 재생 제어의 합작품 |
하지만 답만 모은다고 이 책의 메시지가 되지는 않는다.
진짜 메시지는 그 답들 뒤의 패턴이다.
10.2 세 가지 축으로 본 스트리밍
도입부에서 제시한 세 가지 축을 다시 보자.
지금 우리는 각 챕터를 거치며 이 축들이 어떻게 충돌하는지 모두 보았다.
축 ①: 안정성 ↔ 지연
| 챕터 | 어떻게 등장했는가 |
|---|---|
| 1장 | HLS는 안정성을 위해 지연을 감수했다 |
| 5장 | 그 지연은 4단계에 걸쳐 누적된다 |
| 6장 | LL-HLS는 각 단계의 대기를 잘게 쪼개 줄였다 |
이 축은 끝까지 사라지지 않는다.
버퍼를 줄이면 끊김의 위험이 늘어난다.
WebRTC조차 이 트레이드오프를 피해 가지 못한다. 다만 어느 쪽에 더 무게를 두느냐가 다를 뿐이다.
축 ②: 구조의 단순함 ↔ 성능
| 챕터 | 어떻게 등장했는가 |
|---|---|
| 1장 | HTTP만 쓰는 단순함을 위해 RTMP를 버렸다 |
| 3장 | playlist + segment라는 단순 구조 |
| 6장 | 단순함을 깨지 않으면서 성능을 끌어올리는 시도 |
| 7장 | CMAF로 HLS와 DASH의 단순한 통일 |
LL-HLS는 단순함을 완전히 버리지 않고 성능을 끌어올렸다는 점에서 의미가 있다.
그래서 1초 미만의 초저지연은 결국 다른 프로토콜(WebRTC)에 양보한다.
한 기술이 모든 것을 잘할 수는 없다.
축 ③: 제어권 ↔ 편의성
| 챕터 | 어떻게 등장했는가 |
|---|---|
| 8장 | Flash → 브라우저 → 개발자 |
| 8장 | Safari는 시스템이 통제 |
| 8장 | MMS는 절충 |
이 축은 재생 측의 이야기다.
- 제어권이 개발자에게 있으면 자유롭지만 복잡
- 제어권이 시스템에 있으면 편하지만 제약
Low Latency가 가능했던 건 이 제어권이 개발자에게 넘어왔기 때문이다.
10.3 HLS / LL-HLS / DASH / WebRTC의 위치
세 가지 축 위에 주요 기술을 놓아보면 이렇다.
지연 vs 안정성
실시간성 (낮을수록 빠름)
← →
WebRTC LL-HLS DASH HLS
~200ms ~2s ~5s ~8s
인프라 친화도
| 기술 | HTTP/CDN 활용 | 인프라 비용 |
|---|---|---|
| HLS | ◎ 완전 활용 | 낮음 |
| LL-HLS | ○ 활용 (chunked) | 낮음~중간 |
| DASH | ◎ 완전 활용 | 낮음 |
| WebRTC | ✕ 별도 인프라 | 높음 |
종합 비교
| 항목 | HLS | LL-HLS | DASH | WebRTC |
|---|---|---|---|---|
| 일반 지연 | 6~10초 | 1~3초 | 5~10초 | 0.2~0.5초 |
| 컨테이너 | TS / fMP4 | fMP4 | fMP4 | RTP |
| 매니페스트 | m3u8 | m3u8 | MPD | (없음) |
| iOS 네이티브 | ◎ | ◎ | ✕ | △ |
| Android 네이티브 | △ | △ | ◎ | ◎ |
| 인프라 | HTTP | HTTP | HTTP | UDP + 시그널링 |
| 확장성 | 매우 높음 | 높음 | 매우 높음 | 보통 |
| 양방향 | ✕ | ✕ | ✕ | ◎ |
| DRM | ◎ | ◎ | ◎ | △ |
10.4 어떤 기술을 언제 선택할 것인가
이 책의 끝에서 가장 실용적인 질문은 이거다.
무엇을 골라야 하는가?
답은 단순하다.
무엇이 가장 중요한가에 따라 다르다.
일반적인 결정 기준
1. iOS/Apple TV 호환이 필수인가?
├─ YES → HLS 또는 LL-HLS
└─ NO → DASH도 고려
2. 1초 이하 초저지연이 필요한가?
├─ YES → WebRTC (또는 HESP, SRT)
└─ NO → HLS / DASH 계열
3. 라이브인가 VOD인가?
├─ 라이브 + 짧은 지연 → LL-HLS
├─ 라이브 + 일반 지연 → HLS
└─ VOD → HLS / DASH
4. 글로벌 CDN 활용이 중요한가?
├─ YES → HTTP 기반 (HLS, DASH)
└─ NO → 다른 옵션 가능
5. 콘텐츠 보호가 중요한가?
├─ YES → CMAF + 멀티 DRM
└─ NO → AES-128 정도
시나리오별 추천
| 시나리오 | 추천 |
|---|---|
| 일반 VOD 서비스 | HLS (CMAF, fMP4) |
| OTT 라이브 (스포츠 등) | LL-HLS + CMAF + 멀티 DRM |
| 1:1 비디오 통화 | WebRTC |
| 게임/주식 라이브 (지연 민감) | WebRTC, HESP, SRT |
| 학습 콘텐츠 | HLS + AES-128 또는 토큰 |
| 사내 회의 녹화 | HLS (VOD) |
10.5 이 책의 마지막 한 문장
10개 장을 거쳐 우리가 본 것은 사실 하나의 같은 이야기였다.
- HLS의 등장은 → 연결을 포기하고 요청을 얻은 결과였고
- HLS의 지연은 → 안정성을 얻기 위해 즉시성을 포기한 결과였고
- LL-HLS의 등장은 → 그 포기를 최소화하기 위한 정교한 절충이었고
- CMAF는 → 단순함과 효율을 동시에 잡기 위한 표준이었고
- MSE의 등장은 → 제어권을 개발자에게 넘긴 결정이었다
모든 단계가 같은 패턴이다.
무언가를 얻기 위해 무언가를 포기한 결과.
한 줄로
이 책의 모든 장이 향했던 그 한 문장을 다시 적는다.
HLS는 포맷이 아니라 설계 철학이며, 우리가 마주하는 모든 한계는 그 철학의 자연스러운 결과다.
기술은 바뀐다. HLS는 결국 어딘가에서 새로운 기술로 대체될 것이다.
하지만 트레이드오프라는 관점은 바뀌지 않는다.
다음 기술을 만날 때도
- 이 기술은 무엇을 얻기 위해
- 무엇을 포기했는가
만 묻는다면, 이 책이 했던 일은 그 새 기술에서도 그대로 반복된다.
10장 한 줄 정리
좋은 기술이란 없다. 무엇을 골랐는지 알고 쓰는 기술이 있을 뿐이다.
책을 마치며
여기까지 함께한 여정을 정리하면 이렇다.
1장 HLS는 왜 만들어졌는가
2장 왜 영상을 잘게 나누는가
3장 playlist와 segment의 구조
4장 segment 내부의 실체
5장 왜 HLS는 느린가
6장 그 한계를 어떻게 줄였는가 (LL-HLS)
7장 그것을 가능하게 한 데이터 구조 (CMAF)
8장 브라우저는 어떻게 재생하는가 (MSE)
9장 콘텐츠를 어떻게 보호하는가
10장 이 모두를 어떻게 바라볼 것인가
이제 m3u8을 봐도 TS 패킷을 봐도 fMP4 box를 봐도 MSE 코드를 봐도
“이게 왜 이렇게 생겼지?”
라는 질문에 스스로 답할 수 있을 것이다.
그게 이 책이 하고 싶었던 일이다.